had Fable 5 analyze the state of the schema.

my query:

Analyze the JSON Schema structure under https://github.com/CycloneDX/specification/blob/2.0-tests-init-fixes/schema/2.0/cyclonedx-2.0.schema.json . Ignore all `-bundled` files.

Starting from the root schema , follow every $ref transitively through the files in  (e.g. cyclonedx-metadata, cyclonedx-component, cyclonedx-service, cyclonedx-dependency, cyclonedx-composition, cyclonedx-vulnerability, cyclonedx-annotation, cyclonedx-formulation, cyclonedx-declaration, cyclonedx-definition, cyclonedx-citation, cyclonedx-perspective, cyclonedx-common, cyclonedx-party, cyclonedx-license, cyclonedx-data, cyclonedx-cryptography, cyclonedx-ai-modelcard, cyclonedx-release-notes, cyclonedx-standard, cyclonedx-patent, cyclonedx-jss_X590_2023_10, cyclonedx-api) and check whether the schema makes sense in its current structure. Specifically verify:
Code

- Broken references: every `$ref` (relative file path + JSON pointer like `#/$defs/xyz`) resolves to an existing file and an existing $defs entry in that file. List any $ref that points to a missing file or missing definition.
- `$id` consistency: each file's $id matches its actual path/filename and the expected https://cyclonedx.org/schema/2.0/... convention.
Orphaned files/definitions: model files or $defs entries not reachable from the root schema (excluding the separate cyclonedx-api-2.0.schema.json entry point — check its refs too).
- Circular references that could be problematic, and duplicate definitions of the same concept in multiple files.
- Draft 2020-12 correctness: proper use of $defs, unevaluatedProperties interaction with allOf/$ref (note the root uses unevaluatedProperties: false together with allOf extensibleProperties — check whether this composition works as intended across files), missing $schema declarations, wrong keyword usage, invalid regex patterns, enum/const misuse.
- Naming/structural inconsistencies: inconsistent def naming, inconsistent title/description conventions, anything that looks off (e.g. typos in filenames like jss_X590 vs X.509).

Produce a report of concrete issues found, each with file path, JSON pointer location, and a suggested fix. Also state explicitly which aspects were checked and found to be fine.

I need the report in pastable markdown.

report:

CycloneDX 2.0 JSON Schema Structure Review

Scope: branch 2.0-tests-init-fixes, schema/2.0/cyclonedx-2.0.schema.json + schema/2.0/cyclonedx-api-2.0.schema.json + all 34 files in schema/2.0/model/, excluding *-bundled* files. All $refs followed transitively; every file metaschema-validated against JSON Schema draft 2020-12.

1. Broken / fragile references

All intra-schema/2.0 refs resolve correctly (file + #/$defs/... pointer) — 0 hard-broken refs among the 36 files. However, five refs escape the versioned tree via ../../ and two of them have a real identifier mismatch:

2. $id consistency — ✅ (within 2.0)

Every one of the 36 files has $id exactly matching https://cyclonedx.org/schema/2.0/<path> and its actual path/filename, and $schema: https://json-schema.org/draft/2020-12/schema. The only $id problems are the external http/https mismatches in 1.1–1.3.

3. Orphaned files / definitions

• Files: none orphaned — all 34 model files are transitively reachable from the root schema. ✅
• cyclonedx-api-2.0.schema.json is an empty stub: {"type": "object", "$defs": {}} — no properties, no refs. The README describes it as "the normative API-focused schema [that] reuses CycloneDX models", which it currently does not.
  Fix: implement it or mark it as a placeholder in the README.
• Orphaned $defs (referenced from nowhere, including their own file):

4. Circular references & duplicate definitions

• File-level cycle: cyclonedx-component-2.0.schema.json ⇄ cyclonedx-ai-modelcard-2.0.schema.json (component → modelCard, graphicsCollection; ai-modelcard → componentData). Fully resolvable for validators — not problematic, but worth knowing for code generators. Self-recursive defs (nested components, dependency graph, etc.) are standard and fine.
• Duplicate $defs names across files (14): dependency, flow, hashAlgorithm, identifier (×3), metadata, postalAddress, rating, requirement, requirements, risk, signatures, step, timestamp, trigger.
  • True concept duplicate: postalAddress in common vs party — the party version is a superset (adds isoCode, coordinates). Two competing address models. Fix: keep one (party's) and ref it; delete/alias the other.
  • Intentional but collision-prone: hashAlgorithm and timestamp in cyclonedx-jss_X590_2023_10 deliberately differ from common (IANA names / X.590 clause 6.1 millisecond rule). Fine semantically, but same-named defs across files will clash in naive bundlers/codegen. Fix: prefix jss defs (e.g. jssTimestamp) or namespace during bundling.
  • The rest (dependency in dependency vs requirement, flow, metadata, identifier, rating, risk, step, trigger, …) are genuinely different domain concepts sharing generic names — acceptable, same bundling caveat.

5. Draft 2020-12 correctness

• Metaschema validation: 0 violations in all 36 files. ✅
• Regex patterns: all pattern/patternProperties compile. ✅
• Root composition (unevaluatedProperties: false + allOf: [$ref → common#/$defs/extensibleProperties]): works as intended. In 2020-12, unevaluatedProperties sees annotations from patternProperties inside schemas reached through allOf/$ref, so ext:… properties are correctly allowed at the root while unknown properties are rejected. ✅
• additionalProperties: false + allOf combinations (e.g. component#/$defs/component, behavior#/$defs/behaviorGraph|behaviorNode, vulnerability#/$defs/presenceEvidence, threat categories): verified that no allOf branch introduces property names absent from the parent's properties — all branches are not/if-then constraints on declared properties, so nothing is falsely rejected. ✅ However, this closes those objects to ext: extensions (see §3 baseObject) and mixes two closure idioms (additionalProperties: false vs the root's unevaluatedProperties: false). Suggested fix: standardise on one idiom per the intended extensibility model.
• $schema declarations: present and correct in every file. ✅ No legacy keywords (definitions, boolean exclusiveMinimum, additionalItems) anywhere. ✅ (cyclonedx-definition-2.0.schema.json#/$defs/definitions is a def named "definitions", not the keyword — legal, mildly confusing.)
• specVersion is unconstrained: cyclonedx-2.0.schema.json#/properties/specVersion is required but has only examples: ["2.0"] — any string validates. 1.x schemas pinned it with enum. Fix: add "const": "2.0" (or an enum/pattern).
• Single-value enums (prefer const): cyclonedx-2.0.schema.json#/properties/specFormat (["CycloneDX"]), ai-modelcard#/$defs/energyMeasure/properties/unit (["kWh"]), ai-modelcard#/$defs/co2Measure/properties/unit (["tCO2eq"]), common#/$defs/attachment/properties/encoding (["base64"]), evidence#/$defs/assessmentMethod/allOf/1/.../not (["filename"]). Cosmetic.
• jss…#/$defs/signatureObject sets unevaluatedProperties: true: redundant (open is the default) but intentional and documented via $comment citing X.590 clause 6.2. OK as-is.
• Non-standard meta:enum keyword: used consistently and every meta:enum key set exactly matches its sibling enum values ✅ (established CycloneDX 1.6/1.7 convention).

6. Naming / structural inconsistencies

7. Explicitly checked and found fine

• ✅ All 36 files parse as valid JSON and validate against the draft 2020-12 metaschema (0 errors).
• ✅ All intra-schema/2.0 $refs (file + #/$defs/... pointer) resolve; all pointers into external files (#/definitions/...) also exist.
• ✅ $id ↔ path/filename convention correct in all 36 files; $schema present everywhere.
• ✅ No orphaned model files — every model file is reachable from the root schema.
• ✅ Root unevaluatedProperties: false + allOf → extensibleProperties composition behaves correctly under 2020-12 annotation rules.
• ✅ No additionalProperties: false object is broken by its allOf branches (no branch declares undeclared property names).
• ✅ All regexes compile; serialNumber urn:uuid pattern is correct; patternProperties ^ext:...$ anchored correctly.
• ✅ No required entries missing from properties in closed objects; no duplicate required entries; no unknown format values; no $ref siblings that add conflicting constraints; meta:enum fully consistent with enum everywhere; $defs names uniformly lowerCamelCase.
• ✅ jss_X590 filename is not an X.509 typo — it correctly references ITU-T X.590 (JSS), edition 2023-10.

Priority fixes (summary)

1. Fix http vs https $id mismatch in schema/cryptography-defs.schema.json and schema/spdx.schema.json (breaks $id-based ref resolution from 2.0).
2. Resolve the dead extensibility design: orphaned baseObject + closed objects means ext: properties only work at the BOM root.
3. Implement or clearly stub cyclonedx-api-2.0.schema.json; add the missing cyclonedx-api-2.0-bundled.schema.json or fix the README.
4. Finish or remove common#/$defs/organizationalEntityOrContact (TODO stub); wire up or remove orphaned timestamp/base64 defs (and add pattern to the 48 unvalidated date-time fields if strict validation is intended).
5. Constrain specVersion (e.g. const: "2.0").
6. Deduplicate postalAddress (common vs party); regenerate model/README.md.

actions taken:

1. will not do. the schema has an existing and working and in-use ID
2. might consider - not in the scope of this PR
3. out of scope for this PR
4. out of scope of this PR
5. not planned. it is a free string that needs to stay like this for compatibility reasons with future/previous releases.
6. • postalAddress?? need to look into this - porobably out of the scope of this PR
   • out odscope - see [2.0] docs: update schema/2.0/model/README.md #1035

2 issues flagged by AI (please check if this is valid and relevant, happy to open separate issues if needed):

1. The party model's contact email is now a rich array ("email": [{ "address": "..." }] - this PR migrates fixtures to that), while organizationalContact used by metadata.authors keeps the plain "email": "..." string.
2. SBOM metadata still uses manufacturer and author[] fields, shouldn't those be migrated to the party model?

Edit: Moved to #1037 following comments below.